Internet Surfer 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.387 < prev next >

Wrap

Text File | 1996-02-12 | 28KB | 578 lines

Frequently Asked Questions (FAQS);faqs.387 Also, see the directory PD1:<MSDOS.MOUSE> at Simtel. Q607. How can I access a specific address in the PC's memory? First check the library that came with your compiler. Many vendors have some variant of peek and poke functions; in Turbo Pascal use the pseudo-arrays Mem, MemW, and MemL. As an alternative, you can construct a far pointer: use Ptr in Turbo Pascal, MK_FP in the Turbo C family, and FP_OFF and FP_SEG in Microsoft C. Caution: Turbo C and Turbo C++ also have FP_OFF and FP_SEG macros, but they can't be used to construct a pointer. In Borland C++ those macros work the same as in Microsoft C, but MK_FP is easier to use. By the way, it's not useful to talk about "portable" ways to do this. Any operation that is tied to a specific memory address is not likely to work on another kind of machine. Q608. How can I read or write my PC's CMOS memory? There are a great many public-domain utilities that do this. These were available for download from Simtel as of 31 March 1992: PD1:<MSDOS.AT> CMOS14.ZIP 5965 920817 Saves/restores CMOS to/from file CMOSER11.ZIP 28323 910721 386/286 enhanced CMOS setup program CMOSRAM.ZIP 76096 920214 Save AT/386/486 CMOS data to file and restore ROM2.ARC 20497 900131 Save AT and 386 CMOS data to file and restore SETUP21.ARC 24888 880613 Setup program which modifies CMOS RAM VIEWCMOS.ARC 15374 900225 Display contents of AT CMOS RAM, w/C source At garbo, /pc/ts/tsutle17.zip contains a CMOS program to check and display CMOS memory, but not to write to it. I have heard good reports of CMOS299.ZIP, available in the pc.dir directory of cantva.canterbury.ac.nz [132.181.30.3]. Of the above, my only experience is with CMOSRAM, which seems to work fine. It contains an excellent (and witty) .DOC file that explains the hardware involved and gives specific recommendations for preventing disaster or recovering from it. It's $5 shareware. Robert Jourdain's {Programmer's Problem Solver for the IBM PC, XT, and AT} has code for accessing the CMOS RAM, according to an article posted in this newsgroup. Q609. How can I access memory beyond 640K? I'm outside my expertise on this one, but in late 1992 Jamshid Afshar (jamshid@emx.utexas.edu) kindly supplied the following, which incorporates some corrections agreed with Duncan Murdoch (dmurdoch@ mast.queensu.ca). If you have any corrections or comments, please send them to both the above addresses. ...........................(begin quote)............................ 1. Use XMS or EMS memory. XMS is preferable in most cases, but some machines won't provide it. There are some libraries available at Simtel to access XMS or EMS. The disadvantage is that you don't allocate the memory as you would with malloc() (or `new' in C++). I believe it also requires that you lock this memory when in use. This means your code is not easily ported to other (and future) operating systems and that your code is more convoluted than it would be under a "real" os. The advantage is that the library works with compilers since Turbo C 2.0 (I think) and that your program will easily run on even 286s. 2. Program under MS Windows. MS Windows functions as a 16-bit DOS Extender (see #3). Borland/Turbo C++ 3.x includes EasyWin [and Microsoft C/C++ 7.0 has QuickWin --ed.] which is a library that automatically lets you compile your current code using C/C++ standard input or <conio.h> into a MS Windows program so your code can immediately allocate many MBs of memory (Windows enhanced mode even does virtual memory). The disadvantage is that like any 16-bit Extender a single malloc() is restricted to 64K (unless you want to mess with huge pointers in Windows). Also, EasyWin's screen output is significantly slower than a DOS character-mode program's and you must of course run the program from Windows. 3. Use a 16-bit or 32-bit DOS Extender. This is definitely the best solution from the programmer's standpoint. You just allocate as much memory as you need using malloc() or 'new'. A 16-bit Extender still has 16-bit ints and restricts arrays to 64K, but a 32-bit Extender has 32-bits ints (which makes porting a lot of UNIX code easier) so there are no 64K limits. A 32-bit Extender requires a 32-bit compiler and the program will not run on 286s. Some Extenders also do virtual memory. Using an Extender doesn't require source code changes and unlike option #1 your code is portable and not obsolete in a few months. Your options for this solution are: - Buy PharLap's 16-bit Extender that works with BC++ 3.0+ and MSC (just requires a relink). Note, the BC++ 3.1 upgrade came with PharLap "lite". Pharlap's 32-bit Extender works with 32-bit compilers like [?] - Get the GNU (free,copylefted) gcc 2.x compiler which DJ Delorie ported from UNIX and which uses his 32-bit Extender. It supports C and C++, but the Extender is VCPI which means neither the compiler nor programs it produces will run in a DOS session under Windows. FTP to barnacle.erc.clarkson.edu and get pub/msdos/djgpp/readme. - Get a 32-bit compiler or one that comes with a DOS Extender. Zortech comes with 16-bit and a 32-bit Extenders (no debugger for 32-bit programs, but Flashtek sells one). Watcom also makes a C [and C++?] 32-bit compiler. [If anyone else has products or plans to announce, please let me know.] - Buy Borland Pascal 7.0. It includes a 16 bit royalty-free DOS extender using the same interface as MS Windows. It functions under a DPMI server like Windows or QDPMI from Quarterdeck, and also provides its own server which you can distribute with your programs. 4. This option doesn't really count since it's not a solution in DOS, but you could switch to a full 32-bit operating system like OS/2 2.0 or UNIX (or NT when it comes out). I believe Win32 will allow you to write 32-bit Windows programs. [can someone fill me in on what exactly Win32 is?] ............................(end quote)............................. section 7. Other software questions and problems ================================================ Q701. How can a program reboot my PC? You can generate a "cold" boot or a "warm" boot. A cold boot is the same as turning the power off and on; a warm boot is the same as Ctrl-Alt-Del and skips the power-on self test. For a warm boot, store the hex value 1234 in the word at 0040:0072. For a cold boot, store 0 in that word. Then, if you want to live dangerously, jump to address FFFF:0000. Here's C code to do it: /* WARNING: data loss possible */ void bootme(int want_warm) /* arg 0 = cold boot, 1 = warm */ { void (far* boot)(void) = (void (far*)(void))0xFFFF0000UL; unsigned far* type = (unsigned far*)0x00400072UL; *type = (want_warm ? 0x1234 : 0); (*boot)( ); } What's wrong with that method? It will boot right away, without closing files, flushing disk caches, etc. If you boot without flushing a write-behind disk cache (if one is running), you could lose data or even trash your hard drive. There are two methods of signaling the cache to flush its buffers: (1) simulate a keyboard Ctrl-Alt-Del in the keystroke translation function of the BIOS (INT 15 function 4F), and (2) issue a disk reset (DOS function 0D). Most disk-cache programs hook one or both of those interrupts, so if you use both methods you'll probably be safe. When user code simulates a Ctrl-Alt-Del, one or more of the programs that have hooked INT 15 function 4F can ask that the key be ignored by clearing the carry flag. For example, HyperDisk does this when it has started but not finished a cache flush. So if the carry flag comes back cleared, the boot code has to wait a couple of cluck ticks and then try again. (None of this matters on older machines whose BIOS can't support 101- or 102-key keyboards; see "What is the SysRq key for?" in section 3, "Keyboard".) Here's C code that tries to signal the disk cache (if any) to flush: #include <dos.h> void bootme(int want_warm) /* arg 0 = cold boot, 1 = warm */ { union REGS reg; void (far* boot)(void) = (void (far*)(void))0xFFFF0000UL; unsigned far* boottype = (unsigned far*)0x00400072UL; char far* shiftstate = (char far*)0x00400017UL; unsigned ticks; int time_to_waste; /* Simulate reception of Ctrl-Alt-Del: */ for (;;) { *shiftstate |= 0x0C; /* turn on Ctrl & Alt */ reg.x.ax = 0x4F53; /* 0x53 = Del's scan code */ reg.x.cflag = 1; /* sentinel for ignoring key */ int86(0x15, ®, ®); /* If carry flag is still set, we've finished. */ if (reg.x.cflag) break; /* Else waste some time before trying again: */ reg.h.ah = 0; int86(0x1A, ®, ®);/* system time into CX:DX */ ticks = reg.x.dx; for (time_to_waste = 3; time_to_waste > 0; ) { reg.h.ah = 0; int86(0x1A, ®, ®); if (ticks != reg.x.dx) ticks = reg.x.dx , --time_to_waste; } } /* Issue a DOS disk reset request: */ reg.h.ah = 0x0D; int86(0x21, ®, ®); /* Set boot type and boot: */ *boottype = (want_warm ? 0x1234 : 0); (*boot)( ); } Q702. How can I time events with finer resolution than the system clock's 55 ms (about 18 ticks a second)? The following files, among others, can be downloaded from Simtel: PD1:<MSDOS.AT> ATIM.ARC 5946 881126 Precision program timing for AT PD1:<MSDOS.C> MILLISEC.ZIP 37734 911205 MSC/asm src for millisecond res timing MSCHRT3.ZIP 53708 910605 High-res timer toolbox for MSC 5.1 MSEC_12.ZIP 8484 920320 High-def millisec timer v1.2 (C,ASM) ZTIMER11.ZIP 77625 920428 Microsecond timer for C, C++, ASM PD1:<MSDOS.TURBO-C> TCHRT3.ZIP 53436 910606 High-res timer toolbox for Turbo C 2.0 TCTIMER.ARC 20087 891030 High-res timing of events for Turbo C PD1:<MSDOS.TURBOPAS> BONUS507.ARC 150435 900205 [Turbo Pascal source: high-res timing] Pascal users can download source code in /pc/turbopas/bonus507.zip at garbo. Q703. How can I find the error level of the previous program? First, which previous program are you talking about? If your current program ran another one, when the child program ends its error level is available to the program that spawned it. Most high-level languages provide a way to do this; for instance, in Turbo Pascal it's Lo(DosExitCode) and the high byte gives the way in which the child terminated. In Microsoft C, the exit code of a synchronous child process is the return value of the spawn-type function that creates the process. If your language doesn't have a function to return the error code of a child process, you can use INT 21 function 4D (get return code). By the way, this will tell you the child's exit code and the manner of its ending (normal, Ctrl-C, critical error, or TSR). It's much trickier if the current program wants to get the error level of the program that ran and finished before this one started. G.A.Theall has published source and compiled code to do this; you can download it from Simtel as PD1:<MSDOS.BATUTL>ERRLVL12.ZIP. (The code uses undocumented features in DOS 3.3 through 5.0. Theall says in the .DOC file that the values returned under 4DOS or other replacements won't be right.) Q704. How can a program set DOS environment variables? Program functions that read or write "the environment" typically access only the program's copy of the environment. What this Q really wants to do is to modify the active environment, the one that is affected by SET commands in batch files or at the DOS prompt. You need to do some programming to find the active environment, and that programming varies for different versions of DOS. A fairly well-written article in {PC Magazine} volume 8 number 20 (1989 Nov 28), pages 309-314, explains how to find the active environment, and includes Pascal source code. The article hints at how to change the environment, and suggests creating paths longer than 128 characters as one application. In searching Simtel for source code, I found many possibilities. I liked PD1:<MSDOS.SYSUTL>RBSETNV1.ZIP of the ones I looked at (not all of them). It includes some utilities to manipulate the environ- ment, with source code in C. You can also use a call to INT 2E, Pass Command to Interpreter for Execution; see Ralf Brown's interrupt list for details and cautions. Q705. How can I change the switch character to - from /? Under DOS 5.0, you can't -- not completely, anyway. INT 21 function 3700, get switch character, always returns a '/' (hex 2F) -- and the DOS commands don't even call that function, but hard code '/' as the switch character. Some history: DOS used to let you change the switch character by using SWITCHAR= in CONFIG.SYS or by calling DOS function 3701. DOS commands and other programs called DOS function 3700 to find out the switch character. If you changed the switch character to '-' (the usual choice), you could then type "dir c:/c700 -p" rather than "dir c:\c700 /p". Under DOS 4.0, the DOS commands ignored the switch character but functions 3700 and 3701 still worked and could be used by other programs. Under DOS 5.0, even those functions no longer work, though all DOS functions still accept '/' or '\' in file specs. You can reactivate the functions to get and set switchar by using programs like SLASH.ZIP or the sample TSR called SWITCHAR in AMISL091.ZIP (see "How can I write a TSR?", below.) DOS commands will still use the slash, but non-DOS programs that call DOS func- tion 3700 will use your desired switch character. (DOS replacements like 4DOS may honor the switch character for internal commands.) Some readers may wonder why this is even an issue. Making '-' the switch character frees up the front slash to separate names in the path part of a file spec. This is easier for the ten-fingered to type, and it's one less difference to remember for commuters between DOS and Unix. The switch character is the only issue, since all the INT 21 functions accept '/' or '\' to separate directory names. Q706. Why does my interrupt function behave strangely? Interrupt service routines can be tricky, because you have to do some things differently from "normal" programs. If you make a mistake, debugging is a pain because the symptoms may not point at what's wrong. Your machine may lock up or behave erratically, or just about anything else can happen. Here are some things to look for. (See the next Q for general help before you have a problem.) First, did you fail to set up the registers at the start of your routine? When your routine begins executing, you can count on having CS point to your code segment and SS:SP point to some valid stack (of unknown length), and that's it. In particular, an interrupt service routine must set DS to DGROUP before accessing any data in its data segments. (If you're writing in a high-level language, the compiler may generate this code for you automatically; check your compiler manual. For instance, in Borland and Microsoft C, give your function the "interrupt" attribute.) Did you remember to turn off stack checking when compiling your interrupt server and any functions it calls? The stack during the interrupt is not where the stack-checking code expects it to be. (Caution: Some third-party libraries have stack checking compiled in, so you can't call them from your interrupt service routine.) Next, are you calling any DOS functions (INT 21, 25, or 26) in your routine? DOS is not re-entrant. This means that if your interrupt happens to be triggered while the CPU is executing a DOS function, calling another DOS function will wreak havoc. (Some DOS functions are fully re-entrant, as noted in Ralf Brown's interrupt list. Also, your program can test, in a way too complicated to present here, when it's safe to call non-re-entrant DOS functions. See INT 28 and functions 34, 5D06, 5D0B of INT 21; and consult {Undocumented DOS} by Andrew Schulman. Your program must read both the "InDOS flag" and the "critical error flag".) Is a function in your language library causing trouble? Does it depend on some initializations done at program startup that is no longer available when the interrupt executes? Does it call DOS (see preceding paragraph)? For example, in both Borland and Microsoft C the memory-allocation functions (malloc, etc..) and standard I/O functions (scanf, printf) call DOS functions and also depend on setups that they can't get at from inside an interrupt. Many other library functions have the same problem, so you can't use them inside an interrupt function without special precautions. Is your routine simply taking too long? This can be a problem if you're hooking on to the timer interrupt, INT 1C or INT 8. Since that interrupt expects to be called 18.2 times a second, your routine -- plus any others hooked to the same interrupts -- must execute in less than 55 ms. If they use even a substantial fraction of that time, you'll see significant slowdowns of your foreground program. For a good writeup, download INTSHARE (from ni.funet.fi in pub/msdos/simtel20/info or from Simtel in PD1:<MSDOS.INFO>). Did you forget to restore all registers at the end of your routine? Did you chain improperly to the original interrupt? You need to restore the stack to the way it was upon entry to your routine, then do a far jump (not call) to the original interrupt service routine. (The process is a little different in high-level languages.) Q707. How can I write a TSR (terminate-stay-resident) utility? Several books can help you with this. - Ray Duncan's {Advanced MS-DOS}, ISBN 1-55615-157-8, gives a brief checklist intended for experienced programmers. The ISBN is for the second edition, through DOS 4; but check to see whether the DOS 5 version is available yet. - {DOS 5: A Developer's Guide} by Al Williams, ISBN 1-55851-177-6, goes into a little more detail, 90 pages worth! - Pascal programmers might look at {The Ultimate DOS Programmer's Manual} by John Mueller and Wallace Wang, ISBN 0-8306-3534-3, for an extended example in mixed Pascal and assembler. - For a pure assembler treatment, check Steven Holzner's {Advanced Assembly Language}, ISBN 0-13-663014-6. He has a book with the same title out from Brady Press, but it's about half as long as this one. - For C programmers, there's a chapter in Herbert Schildt's {The Art of C: Elegant Programming Solutions}. I haven't seen the book, but a posted article recommended it. At Simtel, check PD1:<MSDOS.ASMUTL>AMISL091.ZIP, which contains Ralf Brown's assembly-language implementation of the Alternate Multiplex Interrupt Specification, with utilities in C. The spec itself is PD1:<MSDOS.INFO>ALTMPX35.ZIP. Both are also available at CS.CMU.EDU [128.2.222.173] in /afs/cs/user/ralf/pub (change directory with a single command and use lower-case filenames). You might want to download PD1:<MSDOS.ASMUTL>TEMPLATE.ZIP from Simtel. It's Douglas Boling's MASM template for a TSR. Finally, there are commercial products, of which TesSeRact (for C-language TSRs) is one of the best known. Q708. How can I write a device driver? Many books answer this in detail. Among them are {Advanced MS-DOS} and {DOS 5: A Developer's Guide}, cited in the preceding Q. Michael Tischer's {PC System Programming}, ISBN 1-55755-036-0, has an extensive treatment, as does Dettman and Kyle's {DOS Programmer's Reference: 2d Edition}, ISBN 0-88022-458-4. For a really in-depth treatment, look for a specialized book like Robert Lai's {Writing MS-DOS Device Drivers}, ISBN 0-201-13185-4. Q709. What can I use to manage versions of software? In PD1:<MSDOS.PGMUTL> at Simtel you'll find RCS56DOS.ZIP. I haven't used it myself, but I understand this is a port of the Unix RCS utility, and is no longer limited to one-character extensions on filenames (so .CPP and .BAS are fine). Q710. What's this "null pointer assignment" after my C program executes? Somewhere in your program, you assigned a value _through_ a pointer without first assigning a value _to_ the pointer. (This might have been something like a strcpy or memcpy with a pointer as its first argument, not necessarily an actual assignment statement.) Your program may look like it ran correctly, but if you get this message you can be certain that there's a bug somewhere. Microsoft and Borland C, as part of their exit code (after a return from your main function), check whether the location 0000 in your data segment contains a different value from what you started with; if so, they infer that you must have used an uninitialized pointer. To track down the problem, you can put exit( ) statements at various spots in the program and narrow down where the uninitialized pointer is being used by seeing which added exit( ) makes the null-pointer message disappear. Or, in the debugger, set a watch at location 0000 in your data segment, assuming you're in small or medium model. (If data pointers are 32 bits, as in the compact and large models, a null pointer will overwrite the interrupt vectors at 0000:0000 and probably lock up your machine.) Under MSC/C++ 7.0, you can declare the undocumented library function extern _cdecl _nullcheck(void); and then sprinkle calls to _nullcheck( ) through your program at regular intervals. Borland's TechFax document #TI726 discusses the null pointer assignment from a Borland point of view. Download file BCHELP10.ZIP from PD1:<MSDOS.TURBO-C> at Simtel. (continued in part 4) -- Stan Brown, Oak Road Systems brown@Ncoast.ORG Cleveland, Ohio, USA Xref: bloom-picayune.mit.edu comp.os.msdos.programmer:18891 news.answers:4714 Path: bloom-picayune.mit.edu!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!mcsun!uknet!doc.ic.ac.uk!agate!ames!sun-barr!cs.utexas.edu!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!ncoast!brown From: brown@NCoast.ORG (Stan Brown) Newsgroups: comp.os.msdos.programmer,news.answers Subject: comp.os.msdos.programmer FAQ part 4 of 4 Message-ID: <msdos-faq.921220.4@NCoast.ORG> Date: 20 Dec 92 20:15:05 GMT Expires: Wed, 3 Feb 1993 20:15:05 GMT References: <msdos-faq.921220.1@NCoast.ORG> Followup-To: comp.os.msdos.programmer Organization: Oak Road Systems, Cleveland Ohio USA Lines: 446 Approved: news-answers-request@MIT.Edu Supersedes: <msdos-faq.921205.4@NCoast.ORG> Archive-name: msdos-programmer-faq/part4 Last-modified: 20 December 1922 (continued from part 3) (no warranty on the code or information) If the posting date is more than six weeks in the past, see instructions in part 4 of this list for how to get an updated copy. Copyright (C) 1992 Stan Brown, Oak Road Systems section A. Downloads ==================== QA01. What is garbo? What is wustl? These are alternative archive sites. Please try to use the site for your continent; see next Q. QA02. What are Simtel and "mirror sites"? What good are they? The U.S. Government maintains a massive archive of useful software and info files at the SIMTEL20 site. This includes scads of utilities, plus source code from {PC Magazine}, {Dr Dobbs Journal}, and others. You can use Simtel by ftp (wsmr-simtel20.army.mil = 192.88.110.20) or (if necessary) email. To find out how, look for these monthly articles in comp.binaries.ibm.pc.archives : How to find files in the SIMTEL20 msdos collection SIMTEL20 archive info for Internet FTP users How to order SIMTEL20 files via e-mail Another important archive site is garbo (at the University of Vaasa, Finland). garbo is set up differently from Simtel but contains many of the same useful files. Please try first at the site nearest you: - Europe and Asia: look first at garbo; for prerecorded instructions (about 29K), email Timo Salmi (ts@uwasa.fi). - Oceania: try archie.au first. (This is different from the Archie mail server, archie-l@cs.mcgill.ca.) Paul Brooks has written to say that it "mirrors garbo and simtel-20 (in /micros/pc/simtel-20, /micros/pc/garbo) as well as many other archives. Telnetting to 'archie.au' and logging on as 'archie' (no password) will access the Oceanic ARCHIE server." Email Craig Warren (ccw@archie.au) for instructions if needed. - North America: try SIMTEL20 (a/k/a Simtel) first; see above for instructions or email Keith Petersen (w8sdz@vela.acs.oakland.edu). Also see the Simtel mirrors OAK.Oakland.Edu and ftp.uu.net, or the SIMTEL20 & garbo mirror wuarchive.wustl.edu [128.252.135.4]. General cautions and guidelines: - Some of the mirrors may lag occasionally, or might not have all the files. - If you send an email message and don't get a reply within a few days, there are two likely causes. Most likely the Reply-to path in your message is not valid; your sysadmin can check this and correct it if necessary and then you can send your message again. Occasionally a machine goes down for an extended period, which may prevent a timely reply to your message. If you're sure your message bears a good reply path and you haven't got a reply in a week or so, you might send your message again, once. Don't post it as an article in a newsgroup. QA03. Where do I find program <mumble>? There are several newsgroups to help; comp.binaries.ibm.pc.wanted is generally the best place to ask your question. Please review the guidelines in "What other newsgroups should I know about?" in section 1, "General questions". See also the next Q. QA04. How can I check Simtel or garbo before I post a request for a program? What a good idea! It will save your time and save net resources too. Simtel and garbo have indexes of their contents, which you can download and use in searching off line. garbo has an index file, /pc/INDEX, an annotated list, frequently updated, of the MS-DOS files there; to save download time, get the packed form /pc/INDEX.ZIP. The news file, /pc/pd2/news-pd2 contains selected news on all MS-DOS directories at garbo. Simtel's index files are all in PD1:<MSDOS.FILEDOCS>, and are updated several times a month. SIMLIST.ZIP is in text format. But you may prefer the file SIMIBM.ZIP, which is comma-delimited for easy use with any of these search facilities: - Two search programs are SIMTEL35.ARC and SIMDIR22.ZIP. Of the two, I find I use SIMDIR much more often. - dBASE III or IV users can load the index from SIMLIST.ZIP using instructions in SIMIBM.INF and SIMIBM.DB3.